Method of recursive objects for representing hierarchies in relational database systems

ABSTRACT

A method is described for creating and managing a two-level hierarchical data structure. Parent and child object relation tables, an aggregate relation table and a link relation table having records are created wherein each link relation record has an aggregate identity field and a child object identity field and the aggregate relation records have a parent object identity field pointing to a parent object relation record. The link relation records have an aggregate identity field pointing to an aggregate relation record and to a child object relation record whereby zero or more child object relation records are linked to a parent object record relation record.

RELATED APPLICATIONS

[0001] This is a utility application based upon provisional applicationserial No. 60/379,088, filed on May 9, 2002, entitled “Method OfRecursive Objects For Representing Hierarchies In Relational DatabaseSystems.” Applicant hereby claims for this utility application thebenefit of the filing date of the provisional application whose entiredisclosure is incorporated by reference herein.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] Not applicable.

SPECIFICATION BACKGROUND

[0003] 1. Field of Invention

[0004] The present invention relates generally to computer databasesystems and particularly to relational database systems and methods forstoring and retrieving hierarchical data structures.

[0005] 2. Description of Prior Art

[0006] A DataBase is a collection of stored operational data used by theapplication systems of some particular enterprise. [Date, 1986] ADataBase Management System (DBMS) is computer software that providessecure, reliable, shared access to databases whose integrity is assuredvia transaction processing and mechanisms for backup and recovery ofdatabases in the presence of accidental or intentional disruption.

[0007] Note: The term “database” has become widely used and in manycases associated with any collection of data, organized or not. In thisapplication, I use the term written as “DataBase” to distinguish betweenimprecise notions of a database as any collection of data and a DataBaseas a collection of data with an organization that reflects anoperational model for the applications which use it. The more formalnotion will be regarded as consistent with usage by persons skilled inthe pertinent art of database design and applications development.

[0008] As is well understood in the art, the interactive DBMS user orprogrammer of DBMS applications interacts with the DBMS through alogical data model. That model represents an organization of all datainto structured records, structured records into collections, anddefined relationships between and among the records collections. TheDBMS maintains a single, unified physical model of data storage and mapsactions on one or more logical data models to this underlying physicalmodel.

[0009] The Prior Art includes DBMSs which support logical data models ofat least four types: Hierarchical, Network, Relational andObject-Oriented.

[0010] The building block of the Hierarchical Data Model is a two levelone-to-many hierarchy between one parent record of a parent record classP and zero or more child records of a child record class C. A childrecord in a two level P-C hierarchy may be the parent record in anothertwo level C-G hierarchy with parent class C and child class G. Whenviewed in this way, the composition of these two level hierarchies is athree level hierarchy over the classes P, C and G. By extension,hierarchies of any number of levels may be defined and populated withdata. For example, a hierarchy over the classes State, County,Municipality, District, Street and Address could be used to create a sixlevel hierarchy over every addressable building in the United States.Hierarchical DataBase Management Systems (HDBMS) implement theHierarchical Data Model via languages for defining and populatinglogical hierarchies and for logically navigating over hierarchies toretrieve, modify and delete existing records. IBM's IMS, one of thefirst commercial DBMS products conforms to a Hierarchical Data Model.

[0011] The Network Model is similar to the Hierarchical Model, but usesthe equivalent construction of a Set [CODASYL,1969,1971] to representthe simplest one-to-many relationship with Set Owner and Set Member(s)in the roles of hierarchical parent and child(ren). A DBMS based on theNetwork Model provides language constructs for defining, populating andnavigating over these Sets. The commercial product ADABAS is based onthe Network Model.

[0012] The Relational Model presents an entirely different logicalrepresentation as a collection of relational tables, also calledrelations. A relation is a collection of related objects, each objectrepresented by one record (row) of a relation (table). In relationalterminology, the terms relation and table are used interchangeably.However the definition of a relation is derived from a more formal,mathematical characterization, and relations in Relational DataBases aremore restricted in their specification and use than tables. The rows ofa relational table are referred to as tuples, rows or records andrepresent objects. Unlike the hierarchical and network models,relationships between records in different relations are not explicitlyrepresented, but are materialized by the Relational DBMS (RDBMS) inresponse to requests for service called queries. Queries are expressedin a query language. The most popular and standardized for theRelational Model is Structured Query Language, or SQL. An SQL querydefines a response relation in terms one or more relations in theRelational DataBase. The RDBMS treats the query as a request andmaterializes the response relation by accessing the physical storage ofthe referenced relations. In effect, an SQL query defines a relation anda RDBMS materializes the defined relation. An RDMBS typically providesboth an interactive end user interface and a programmatic (or “call”)interface. The interactive interface simply materializes all responserecords. The call interface also includes programming language functionsfor navigating backwards and forward through the set of responserecords. Note that individual relations act as containers, and thatrelationships between these containers are not explicitly represented.

[0013] Object-Oriented (OO) DataBase Management Systems (OODBS) supportthe same generic modeling capability that characterizes and haspopularized Object-Oriented Programming Languages like ADA [Booch,1983]and C++[Lippman,1991]. From the perspective of an application written inan OO programming language, an OODB (Object-Oriented DataBase) providesstorage for data that are activated (retrieved) as needed and passivated(stored back to the DataBase) when no longer needed. Navigation isimplicit in the relationships between and among object types, so thatactual OODB access requires very little additional skill beyond theability to program in these languages. This natural fit betweenObject-Oriented Programming Languages and Object-Oriented DataBaseManagement Systems makes the latter especially valuable in environmentscharacterized by a heavy software development workload and therequirement of large volumes of shared, persistent data.

[0014] Historically, the first DBMSs commercially available were basedon the Hierarchical and Network models. These products were introducedin the late 1950s and early 1960s. The Relational Model of Data wasintroduced in a seminal paper in 1970 by E. F. Codd [Codd, 1970]. TheRelational approach to databases touched off a revolution in databaseresearch and development. The first experimental RDBMSs were developedin the middle 1970's: IBM's System R [Astrahan,1976] and INGRES[Stonebraker,1976]. By the late 1970's, commercial RDBMS products likeOracle, Sybase and IBM's DB2 became available. Sales growth for RDBMSsexploded and relational technology became the dominant technology in newbusiness, scientific and engineering applications. Hierarchical andNetwork DBMSs continued to be used, though mainly in legacy systems.

[0015] In the mid 1980's, growth in the popularity of Object-OrientedProgramming Languages for applications development leveraged growth inthe Object-Oriented segment of the DBMS market. It appeared that OODBMStechnology might displace RDBMS technology just as RDBMS technology hadsupplanted the earlier hierarchical and network technologies. That didnot in fact occur. For enterprises that have developed large DataBasesand devote major expense to applications development, Object-OrientedProgramming Languages have proven to be more cost effective than earliersoftware development approaches, and many of these organization continueto use OODBMSs. However, for reliable data management, RDBMSs and therelational approach consistently dominate the market for commercialDBMSs. Some OODBMS vendors implement an Object-Oriented data model usingan RDBMS, thus offering the best of both worlds: Efficient softwaredevelopment against an OO logical model and the reliability andflexibility of the relational model for database management andpreservation of these valuable assets.

[0016] The value of large data collections can almost always be enhancedthrough use of a DBMS, and the Relational DBMS is the overwhelmingchoice for business, science and engineering. Many data managementapplications are well matched to the tabular view of data provided bythe relational model of data provided by an RDBMS. But many others arefar easier to approach when the data can be organized hierarchically.Because RDBMSs are widely available and provide such high levels ofsecurity and reliability, several innovators have attempted to developtechniques for representing hierarchies and other related datastructures using Relational DataBases and the SQL query language. ThePrior Art for such techniques includes the following:

[0017] Goldberg et. Al. [U.S. Pat. No. 5,201,046, 1993] describe a“method for storing, retrieving and modifying directed graph datastructures” using an RDBMS. A hierarchy is a restricted case of adirected graph, so that a directed graph technique could also be used torepresent hierarchies in a RDB. The approach extends the SQL querylanguage with two new languages constructs (“EXPAND” and “DEPTH <N>”)and a new data type (“REFERENCE”) to represent a pointer from a recordin one relation to a record in a second (possibly the same) relation.

[0018] Simonetti [U.S. Pat. No. 5,295,261, 1994] describes a “Hybriddatabase structure linking navigational fields having a hierarchicaldatabase structure to informational fields having a relational databasestructure”. In this method, that portion representing the hierarchicaldatabase structure is contained in a topological map stored as a fileexternal to the relational database.

[0019] Sacks [U.S. Pat. No. 5,974,407, 1999] describes a “Method andapparatus for implementing a hierarchical database management system(HDBMS) using a relational database management system (RDBMS) as theimplementing apparatus”. The method employs the Relational DataBase as avirtual (mechanical) means for implementing a Hierarchical DataBaseManagement System (HDBMS). The schema of the individual hierarchicaltables, the permissible parent-child relationships in the HierarchicalDataBase, the definitions of subset views and the actual representationof an individual hierarchy is captured in five relations. A sixthrelation makes it possible to store multiple hierarchies in the sameHierarchical DataBase. Access to the underlying Relational DataBaseManagement Systems and other Relational DataBases are allowed, but thehierarchical data itself cannot be correctly interpreted via the SQLmechanism without the interface specified in the patent implemented inan appropriate programming language.

[0020] Jagadish [Jagadish, 1989] describes a method for “IncorporatingHierarchy in a Relational Model of Data,” but his method requiresextensions to the SQL query language and a new data type. Millett[Millett, 2001] provides two methods for “Accommodating Hierarchies inRelational Databases”. The first (Path approach) involves the use of a“navigation bridge table” relation that stores all pairwise parent-childlinks of a hierarchy. The second (Denormalized Unit Table approach) issuitable only where the maximum number of levels in the hierarchy isknown a priori. In this method, a data record in a relation thatparticipates in a hierarchy includes pointers to each of its ancestors.

[0021] Finally, note the industry standard for the SQL query language,ANSI/ISO/IEC 9075-2-1999 [ISO/SQL,1999]. The most recent update to thisstandard includes a “WITH RECURSIVE ORG” statement which defines anoperation for retrieving the transitive closure of a directed graph overa hierarchy of relations and the computation of aggregate values overelements of that hierarchy. This standardized extension to the SQL querylanguage indicates interest in representing directed graphs (digraphs)in Relational DataBases, but the feature is not widely available incommercial RDBMS products and is restricted to a style of hierarchicalrepresentation in which pointers to parents are stored within datarecords. Implicitly, this limits a record in a relation to participateonly in as many hierarchies as the number of fields defined for thatpurpose. The reason for this limit is as in Millett, above: Because onerecord field is required for each hierarchy within which the recordparticipates, the number of such hierarchies must be known when theschema is defined, before any records are inserted into the hierarchy.

[0022] All Prior Art techniques suffer from one or more of the followinglimitations:

[0023] Limitation 1: Use of non-SQL language extensions, or non-nativedata types, or both. Modifications to SQL or addition of non-trivialdata types is not permitted by commercial products. This is becausenon-SQL language extensions imply the addition of internal searchmechanisms, and, non-native data types cannot be correctly interpretedby a standard RDBMS. Goldberg introduces the “REFERENCE” data type andthe EXPAND and DEPTH <N>language constructs to SQL. Sacks employscomposite keys and a front end interface to interpret them. Applicationswhich conform to SQL standards are portable; applications whichintroduce language extensions and/or non-native data types are not. Thislimitation eliminates one of the primary advantages for using a standardRDBMS to implement hierarchies.

[0024] Limitation 2: Use of external data structures to represent thehierarchies. RDBMSs only support relations as containers for datarecords. There are no other storage structures. The use of external datastructures (typically in files) implies that the security, protection,backup/recovery and overall integrity that the RDBMS provides forrelations is not available. Simonetti uses an external topological mapto represent the hierarchical structure.

[0025] Limitations 3: Prohibition against arbitrary hierarchies limitsapplicability. The Millett Denormalized Unit Table Approach requires apriori knowledge of the maximum number of levels in a hierarchy. TheMillett Path Table Approach can only represent a single hierarchy. Formultiple hierarchies, each requires a separate Path Table. Inapplications where entire hierarchies are manipulated (combined ordeleted for example), there are no obvious methods for treatingsubhierarchies as attachable/detachable units. Any technique in whichparent- and/or child pointers are included in data relations implicitlylimits the number of hierarchies in which the records of that relationcan participate and reduces the generality of the approach.

[0026] Limitation 4: The Relational representation of records in thehierarchies is proprietary. That is, it is subject to correctinterpretation only by specialized interface software. As a consequence,such data cannot also be accessed and correctly interpreted by theinteractive user or programmed application via the conventional SQLinterface to the RDBMS. The Sacks method suffers from this limitation.

[0027] Limitation 5: The implementation is too complex for all but themost skilled practitioners of relational database art. Simonetti andSacks both require extensive front-end development. The Miller/Pathapproach involves the INNER JOIN operator which is not understood bymost SQL programmers.

[0028] In contrast, the current invention is entirely implemented withina standard Relational DataBase Management System with no languageextensions to the standard SQL query language, no new data types and nospecialized front end interface. Unlike Goldberg, Sacks and Jagadish,the current invention is portable across all SQL compliant RDBMSs. Thecurrent invention employs no external data structures or files, so thatall benefits of the DBMS approach are obtained. This is in contrast toSimonetti, who uses an external topological map. In the currentinvention, there are no artificial limits on the numbers of hierarchies,the number of levels in a hierarchy, or the number of hierarchies inwhich a record in any relation may simultaneously participate. Inaddition, a record may participate multiple times as a child in ahierarchy and at any number of levels within any hierarchy. This is incontrast to Millett who limits the number of levels in the hierarchy orthe number of hierarchies. The current invention permits relationalaccess to the underlying data: All relational data records participatingin hierarchies are accessible via the standard SQL relational querymechanism. This is in contrast to Sacks, where a Hierarchical DataBasemay coexist with a Relational DataBase since both are supported by aRelational DataBase Management System, but access to the RelationalDataBase via Hierarchical views or access to the Hierarchical DataBasevia Relational views is not possible. In an applications environmentthat employs Relational DataBases, the Hierarchical views provided bythe current invention may be introduced without disruption to orreprogramming of existing applications. And finally, the presentinvention implementation is simple, straightforward and robust.

2. References Cited in Description of Prior Art

[0029] [Astrahan,1976]

[0030] Astrahan, M. M., M. W. Blasgen, D. D. Chamberlin, K. P. Eswaran,J. N. Gray, P. P. Griffiths, W. F. King, R. A. Lorie, P. R. McJones, J.W. Mehl, G. R. Putzolu, I. L. Traiger, B. W. Wade, V. Watson, “SystemR”, ACM Transactions on Database Systems (TODS), June 1976.

[0031] [Booch, 1983]

[0032] Booch, Grady, “Software Engineering with Ada”, Benjamin-CummingsPublishing Company, Inc., Menlo Park, Calif., 1983.

[0033] [CODASYL,1969]

[0034] CODASYL Systems Committee, “A survey of generalized data basemanagement systems,” Technical Report, May 1969.

[0035] [CODASYL,1971]

[0036] CODASYL Systems Committee, “Feature analysis of generalized database management systems,” Technical Report, May 1971.

[0037] Codd, 1970]

[0038] Codd, E. F., “A Relational Model of Data for Large Shared DataBanks,” Communications of the ACM, vol. 13, no. 6, pp.377-387, June1970.

[0039] [Date, 1986]

[0040] Date, C. J., “An introduction to Database systems, 3rd Edition”,Reading, Mass., Addison-Wesley, 1986.

[0041] [Jagadish, 1989]

[0042] Jagadish, H. V., “Incorporating hierarchy in a relational modelof data”, Proceeding of 1989 International SIGMOD Conference, pp.78-87,ACM, 1989.

[0043] [ISO/SQL,1999]

[0044] International Organization of Standardization (ISO), DatabaseLanguage SQL, ANSI/ISO/IEC 9075-2-1999

[0045] [Lippman,1991]

[0046] Lippman,S. B., “C++Primer”, Addison-Wesley, 1991

[0047] [Millet, 1999]

[0048] Millet, Ido, “Accommodating Hierarchies in Relational Databases”,in Developing quality complex database systems: Practices, techniquesand technologies, Idea Group Publishing, Hershey, Pa., USA, pp.194-209.

[0049] [Stonebraker,1976]

[0050] Stonebraker, M., “The Design and Implementation of Ingres,” ACMTransactions on Database Systems, September 1976.

BRIEF SUMMARY OF THE INVENTION

[0051] The object of the present invention is to provide a method forrepresenting hierarchical organizations of data in a RelationalDataBase. The method is called the Method of Recursive Objects. Theinvention consists of a main embodiment and three alternate embodiments,all of which are schema designs using the Relational Model of Data. Eachembodiment provides for the construction of a building block unit calledan aggregate to construct a two level hierarchy. One aggregate links oneparent record to zero or more child records. When the child record ofone aggregate is the parent record of another aggregate, the aggregatesmay be combined and composed to produce a three level hierarchy. Byextension, hierarchies of any desired level may be constructed.

[0052] It is a feature of the present invention that the implementationcan be contained entirely within a Relational DataBase and completelymanaged by an industry standard SQL Relational DataBase ManagementSystem. The present invention employs the Relational Model of Data asexpressed by the current standard SQL query language without extensionsor modifications, and without introducing any new data types.Implementations are portable across all industry standard SQL RelationalDataBase Management Systems.

[0053] It is a feature of the present invention that the implementationimposes no restrictions on the number of hierarchies, on the number ofaggregates a database record may participate in, the number of times adatabase record may occur as a child in an aggregate, or theco-occurrence of a database record as both parent record and childrecord in an aggregate.

[0054] Unlike the Prior Art, the present invention may be implemented inan industry standard SQL Relational DataBase Management System withoutthe use of external files. The advantage this confers is that all datainvolved in implementations of the present inventions are managed by theRelational DataBase Management System and therefore gain all thebenefits provided by the DataBase Management System. That typically willinclude security, reliability, shared access, privacy, transactionprocessing, backup and recovery.

[0055] Unlike the Prior Art, the present invention imposes no limits onthe hierarchies which may be defined. In its four embodiments, it may beapplied to the representation of hierarchies over multiple relations ina single Relational DataBase. It may be applied to the representation ofdirected graphs over a single relation in a Relational DataBase. It maybe applied to the representation of arbitrary hierarchies of enumeratedtyped records. It may be applied to the representation of arbitraryhierarchies over data records in different Relational DataBase relationsdistributed over networks of Relational DBMS Servers. The advantage thisconfers is generality to a wide variety of applications.

[0056] Like the Prior Art, the present invention may be used toconstruct new, Hierarchical DataBases. Unlike the Prior Art, the presentinvention may also be used in the construction of hierarchical viewsover existing Relational DataBases requiring only unintrusive readaccess to the underlying relations. As a consequence and advantage,existing applications against those Relational DataBases can continue tooperate without modification. New applications using the HierarchicalViews may be created with absolutely no impact on applications alreadyin operation against the original, Relational DataBase.

[0057] The present invention is simple and robust.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

[0058]FIG. 1 shows a four relation schema diagram for representingaggregates (two hierarchies) according to the Main Embodiment.

[0059]FIG. 2 provides the SQL statements to define the four relations ofthe Main Embodiment.

[0060]FIG. 3 provides SQL statements to define four relations forExample 1, an aggregate (two level hierarchy) linking Teams to Players.

[0061]FIG. 4 shows four relational tables with sample data for Example1.

[0062]FIG. 5 shows a graphical depiction of the two level Team-Playerhierarchy of Example 1 using the data of FIG. 4.

[0063]FIG. 6 provides SQL statements to define three relations forExample 2. When added to the four relations of Example 1, a three levelLeague-Team-Player hierarchy is created.

[0064]FIG. 7 shows three relational tables with sample data for Example2.

[0065]FIG. 8 shows a graphical depiction of the three level hierarchy ofExample 2 using the data of FIG. 7.

[0066]FIG. 9 shows Alternate Embodiment #1, a special case of the MainEmbodiment in which the ParentObject relation and ChildObject relationare the same.

[0067]FIG. 10 provides SQL statements to define the three relations ofAlternate Embodiment #1.

[0068]FIG. 11 provides SQL statements to define three relations forExample 3 according to Alternate Embodiment #1.

[0069]FIG. 12 shows sample data for Example 3 in tabular form.

[0070]FIG. 13 shows the directed graph equivalent for Example 3 usingthe sample data from FIG. 12.

[0071]FIG. 14 shows a schema diagram for Alternate Embodiment #2.

[0072]FIG. 15 provides SQL statements to define the six relations inAlternate Embodiment #2.

[0073]FIG. 16 shows a schema diagram for Alternate Embodiment #2 withoutthe LinkType relation.

[0074]FIG. 17 shows a schema diagram for Alternate Embodiment #2 withoutthe AggregateType relation.

[0075]FIG. 18 shows a schema diagram for Alternate Embodiment #2 withoutboth the LinkType and AggregateType relations.

[0076]FIG. 19 shows a schema diagram for Alternate Embodiment #3.

DETAILED DESCRIPTION OF THE INVENTION

[0077] The present invention is called the Method of Recursive Objectsand consists of schema designs for linking one record in a parent recordclass to zero or more records in a child record class into a two levelhierarchy called an aggregate. When a child record in one aggregate isthe parent record in a second aggregate, the combination of the twoaggregates is interpreted as a three level hierarchy. By extension,hierarchies of any number of levels over any combination of objectrecord classes may be defined. The Method of Recursive Objectsrepresents arbitrary hierarchies and related data organizationstructures using an industry standard SQL Relational DataBase toimplement the four embodiments of an aggregate.

[0078] The Main Embodiment of the Method of Recursive Objects is thefour relation schema design illustrated in FIG. 1. These schema diagramsand the implied organization of data records within relations will befamiliar to persons of ordinary skill in the pertinent art of RelationalDataBase design, and in the development of software applicationsinvolving access to Relational DataBases. Such persons will recognizethat the schema diagrams contained herein depict relations andrelationships between relations, and that relation names and field namesare chosen for clarity of exposition. The schema designs of the Methodof Recursive Objects are independent of the choice of relation and fieldnames made by all those who would implement the Method.

[0079]FIG. 1 defines a schema organization for the Main Embodimentconsisting of four relations: The ParentObject relation contains recordswhich may fill the role of parent record in an aggregate. TheChildObject relation contains records which may fill the role of childrecord(s) in an aggregate. The Aggregate relation contains aggregaterecords each of which represents an aggregate. An aggregate recordpoints to a single parent record in ParentObject relation. The Linkrelation completes the construction of aggregates. The Link relationcontains link records, each with two pointers, one pointing to theaggregate in the Aggregate relation and the other pointing to a childrecord in the ChildObject relation. Notice that there are no pointersfrom the Aggregate relation to the ChildObject relation, nor from theLink relation to the ParentObject relation. This separation of pointersinto individual relations is an essential feature of the Method ofRecursive Objects and differentiates the Method of Recursive Objectsfrom the Prior Art.

[0080] The FIG. 1 schema diagram shows four relations and those pointersthat are essential to the Method. That is, the ParentObject,ChildObject, Aggregate and Link relations, and the pointer fields fromAggregate to ParentObject, from Link to Aggregate, and from Link toChildObject.

[0081]FIG. 2 provides prototype SQL statements to define the fourrelations for the Main Embodiment schema diagram of FIG. 1. Onlyrequired fields and pointers in the Aggregate and Link relations areshown. A person skilled in the pertinent art would appreciate thatadditional fields may be added to the schemas. For example, fields couldbe added to the ParentObject and ChildObject record schemas to describeand characterize the objects each represents. And that an aggregate namefield may be added to the Aggregate relation schema for clarity. Andthat a primary key link id field may be added to the link relationschema for performance. None of these additional fields changes thefundamental spirit of the Method of Recursive Objects. Example 1illustrates aggregate definition and includes added fields.

EXAMPLE 1

[0082] Construction of Team-Player aggregates. Let the Team relationrepresent teams (or team objects) acting in the role of the ParentObjectrelation. Let the Player relation represent players (or player objects)acting in the role of the ChildObject relation. The Team relation schemaincludes fields for the City in which the team plays and the team'smascot. The Player relation includes field values for the player's dateand place of birth. FIG. 3 shows the SQL statements to define the fourrelations for Example 1 including these additional fields. FIG. 4 showssample data for Example 1 in tabular form. FIG. 5 shows a graphicalrepresentation of the two level hierarchy of Example 1. Note in FIGS. 4and 5 that a child Object may be a child in more than one aggregate.Example 1 contains three hierarchies corresponding to the threeaggregates, Mudhens Roster, Mighty Ducks Roster and All Stars.

EXAMPLE 2

[0083] To extend the aggregates (two level hierarchies) of Example 1into a three level hierarchy, a new relation (League) is added plus anew Aggregate relation (LeagueTeamAggregate) and a new Link relation(LeagueTeamLink). FIG. 6 shows the SQL statements to define theadditional relations. FIG. 7 shows additional sample data for Example 2in tabular form. FIG. 8 shows the three level hierarchy of Example 2 ingraphical form.

[0084] Note the following features of the Main Embodiment:

[0085] A parent record may be the parent record in any number ofaggregates.

[0086] A child record may fulfill the role of child in any number ofaggregates.

[0087] A child record may fulfill the role of child zero or more timeswithin an aggregate. The implementer may choose to prevent multipleoccurrences of a child record in an aggregate by software, through theuse of unique keys in the schema definition, software or some othermechanism.

[0088] Schemas for the Aggregate relation and Link relation in FIG. 1are specific to the Parent Object and Child Object relations. To defineand instantiate an arbitrary hierarchy, one Aggregate relation and oneLink relation are required for each pair of relations for which therepresentation of a parent-child relationship (i.e., an aggregate) isrequired.

[0089] Although the composite structure of aggregates is said to form ahierarchy, there are no restrictions on closed paths or cycles withinthe structure. It would therefore be more correct to equate thestructures assembled from aggregates to lattice structures rather thanto hierarchical structure. Hierarchical structures are a subset oflattice structures. Persons skilled in the pertinent art could use theMethod of Recursive Objects to implement lattices, or, could enforce ahierarchical structure through detection and prohibition via software,database constraints or some other mechanism of closed loops or cycles.

DETAILED DESCRIPTION OF THE ALTERNATE EBODIMENT #1

[0090] Embodiment #1 of the Method of Recursive Objects is the threerelation schema design illustrated in FIG. 9. FIG. 9 defines a schemaorganization consisting of three relations: The Object relation containsrecords which may fill the role of parent and child records in anaggregate. The Aggregate relation contains aggregate records, each ofwhich represents one aggregate and contains a pointer to the parentrecord in the Object relation. The Link relation completes theconstruction. The Link relation contains Link records with two pointers,one which points to an aggregate record in the Aggregate relation andthe other which points to a child record in the Object relation.Alternate Embodiment #1 differs from the Main Embodiment only insofar asthe ParentObject relation and ChildObject relation are the singlerelation specified as Object in FIG. 9 and defined in FIG. 10. SQLstatements to define all three relations for Alternate Embodiment #1 aregiven in FIG. 10. Alternate Embodiment #1 represents a specialization ofthe Main Embodiment in which all parent and child records are drawn froma single class, the Object relation. This schema design permits exactlythe same hierarchical structures as the Main Embodiment, but personsskilled in the pertinent art will recognize that if multiple occurrencesof any one record as parent record in an aggregate are prohibited andmultiple occurrences of any one record as child record in an aggregateare prohibited, and aggregates where the child record and parent recordare identical are prohibited, then the resulting structures areequivalent to directed graphs over the records in the Object relation.

EXAMPLE 3

[0091] A digraph representation of an Organization Chart. Let the set ofrecord objects be the Employees of Company X. Company X is organizedinto Groups, each of which has one Employee leader (parent role) andzero or more Employee members (child role). FIG. 11 shows the SQLstatements to define the three relations according to AlternateEmbodiment #1. FIG. 12 shows sample data for Example 3 with 9 Employeesorganized into five groups. FIG. 13 provides a graphical depiction ofthe Organization Chart of Example 3.

[0092] Many applications employ directed graphs as data structure. WithAlternate Embodiment #1, it is possible to completely represent directedgraphs over a single relation using a Relational DataBase ManagementSystem. Unlike the Prior Art, the Method of Recursive Objects isentirely implemented within a RDBMS without the use of any external dataor files.

[0093] Note the following features of Alternate Embodiment #1:

[0094] Parent and child records are drawn from a single record classcorresponding to the Object relation.

[0095] A record may be the parent record in any number of aggregates anda record may have multiple occurrences as a child in an aggregate. Theresulting structure will represent a digraph only if records arerestricted to being the parent record in at most one aggregate and ifrecords are restricted to at most one occurrence as a child in anyaggregate and if records are restricted so that an aggregate may nothave the same record as both parent and child.

[0096] Schemas for the Aggregate relation and Link relation in FIG. 9are specific to a single digraph. For each digraph, a separate pair ofAggregate and Link relations is required.

DETAILED DESCRIPTION OF THE ALTERNATE EMBODIMENT #2

[0097] Alternate Embodiment #2 of the Method of Recursive Objects is thesix relation schema design illustrated in FIG. 14. Alternate Embodiment#2 represents a variation on Alternate Embodiment #1 in which the Methodof Recursive Objects is used to create arbitrary hierarchies overrecords drawn from a single Object relation whose objects (i.e.,records, rows, tuples) are partitioned into object types enumerated inthe ObjectType relation. Each object record in the Object relationspecifies its object type using a pointer to an object type record inthe ObjectType relation. In addition to using object types to classifyobjects, Alternate Embodiment #2 partitions aggregates into typedclasses according to an enumerated set of aggregate types in theAggregateType relation,and partitions Links into typed classes accordingto an enumerated set of link types in the LinkType relation. AlternativeEmbodiment #2 is similar to the Main Embodiment in that it can representarbitrary hierarchies over typed classes, but achieves this usingenumerated types for objects. This is in contrast to the Main Embodimentwhere membership in different database relations determines membershipin either the parent class (ParentObject relation) or the child class(ChildObject relation) in FIG. 1.

[0098]FIG. 14 defines a schema organization consisting of six relationsfor Alternate Embodiment #2. In FIG. 14:

[0099] Each record of the Object relation points to an object type inthe ObjectType relation;

[0100] Each record of the Link relation points to a link type in theLinkType relation;

[0101] Each record of the Aggregate relation points to an aggregate typein the AggregateType relation;

[0102] Each aggregate type record in the AggregateType relationspecifies (points to) one parent object type record in the ObjectTyperelation, one child object type record in the ObjectType relation, andone link type record in the LinkType relation. An aggregate (record)which points to this aggregate type (record) must connect parent andchild objects (records) of the prescribed types using a link (record) ofthe prescribed type. This is enforced by integrity constraints orsoftware or some other mechanism.

[0103] The SQL statements to define the six relations of AlternateEmbodiment #2 in FIG. 14 are shown in FIG. 15.

[0104] Alternate Embodiment #2 provides a powerful means forconstructing arbitrary hierarchies over nonhomogeneous objects usingonly six relations. It is often possible to superimpose hierarchies overan existing Object relation where the Object relation schema includes afield value that partitions the set of Objects. In that case, theObjectType relation captures these type values (types) and the aggregatetype defines the desired parent-child relationships between the objecttypes and the link type.

[0105] The enumerated type relations for aggregates (i.e.,AggregateType) and for links (i.e., LinkType) provide an extra measureof strong typing that applications or interface software can enforce forinternal consistency. Either or both the AggregateType and the LinkTyperelations may be omitted along with the corresponding pointers from theAggregate and Link relations. The resulting schema designs lack thestrong typing mechanism of FIG. 14, but are still implementations ofAlternate Embodiment #2. FIG. 16 shows Alternate Embodiment #2 with theLinkType relation and pointer from Link to LinkType omitted. FIG. 17shows Alternate Embodiment #2 with the AggregateType relation andpointer from Aggregate to AggregateType omitted. FIG. 18 shows AlternateEmbodiment #2 with both the LinkType and AggregateType relationsomitted, as well as omitting the pointer from Link to LinkType and thepointer from Aggregate to AggregateType.

DETAILED DESCRIPTION OF THE ALTERNATE EMBODIMENT #3

[0106] Alternate Embodiment #3 of the Method of Recursive Objects is theseven relation schema organization illustrated in FIG. 19. AlternateEmbodiment #3 incorporates the structure of the Main Embodiment with thetype mechanism of Alternate Embodiment #2. The left side of FIG. 19 isidentical to the schema of FIG. 1 (Main Embodiment). The right side ofFIG. 19 is analogous to the typing mechanism on the right side of FIG.14, the schema design for Alternate Embodiment #2. As in FIG. 14, anaggregate points to an aggregate type record in the AggregateTyperelation and a Link points to a link type record in the LinkTyperelation. The aggregate type of the aggregate specifies the link type,so that only link records of the correct type may be used. In AlternateEmbodiment #3, the ParentObject relation and the ChildObject relationare not required to exist in the same Relational DataBase. Instead: Theymay be any relations in any Relational DataBases managed by anyRelational Server on a network. The only requirement is that they beaccessable with read permission. The network may be a local area net(LAN), or it may be a wide area net (WAN) such as the Internet. TheObjectTypeDescriptor of FIG. 19 serves as a type classificationmechanism just as ObjectType in Alternate Embodiment #2, but neither theParentObject relation nor the ChildObject relation in FIG. 19 containsany pointers to object type descriptor records in theObjectTypeDescriptor relation. Instead, the ObjectTypeDescriptor recordsprovide the information necessary to retrieve a record from an Objectrelation (Parent, or Child) by specifying the network address of thehost Relational Server, the name and owner of the Relational DataBase,the name of the relation, and fields of the relation (ParentObject orChildObject) used to implement the pointers from the aggregate and linkrecords. A person skilled in the pertinent art will recognize that forthe Aggregate relation and Link relation to point to records inrelations on the network, the pointers must be interpreted as uniquenetwork addresses. The fields specified in the ObjectTypeDescriptorrelation are combined with either the parent record pointer in anaggregate record or the child record pointer in a link record to producea network address which uniquely identifies the parent record or childrecord in the correct relation in the network.

[0107] Because Alternate Embodiment #3 does not require pointers fromthe ParentObject or ChildObject relations, the Method of RecursiveObjects can be implemented over all relations in all RelationalDataBases managed by all Relational Servers in a network withoutmodification to any of their schemas and without data modification toany of the participating records. (That is, with only read accesspermission.) Alternate Embodiment #3 therefore allows for theconstruction of arbitrary hierarchies across all relations residing onall network Relational Servers. The Prior Art contains no known methodfor constructing equivalent structures using a Relational DataBase andRelational DataBase Management Systems as the implementing apparatus.

CONCLUSION, RAMIFICATION AND SCOPE

[0108] The present invention provides a mechanism for implementing theMethod of Recursive Objects for the representation of several variationsof arbitrary hierarchies. These include hierarchies over classes definedby relations, digraphs over the records of any single relation,hierarchies over records of any single relation partitioned byenumerated types, and hierarchies over classes defined by relationsstored on any Relational Server in a network.

[0109] In all 4 embodiments, the Aggregate relation and Link relationcombine to provide aggregates, which are the building blocks forhierarchies. In general, the child records in a hierarchy are unordered.Persons skilled in the pertinent art will understand that a retrievalorder can be imposed on the child records by providing a suitable fieldin the relational schema of the Link relation. Examples include adatetime field for time ordering or an integer or floating point fieldfor numeric ordering. The presence of such fields does not alter thespirit and scope of the invention. The essential new aspect of thepresent invention is the aggregate and the four embodiments of anaggregate using only relations in a Relational DataBase. It will beunderstood by those skilled in the pertinent art that the relation namesand fields names may be chosen by the implementer and new fields addedwithout departing from the spirit and scope of the invention.

What is claimed is:
 1. A method of recursive objects for representing atwo level hierarchy called an aggregate that associates one record of afirst, parent class and zero or more records of a second, child class,each said class defined by the records of a relation within a relationaldatabase, comprising the steps of: (a) defining an aggregate relationwith a record schema including at least a first aggregate field touniquely identify one aggregate record among all aggregate records insaid aggregate relation, and a second aggregate field to uniquelyidentify one parent class record among all parent class records in saidparent class relation; (b) defining a link relation with a record schemaincluding at least a first link field to uniquely identify one aggregaterecord among all aggregate records in said aggregate relation, and asecond link field to uniquely identify one child class record among allchild class records in said child class relation; (c) representing saidaggregate by (i) storing one record in the aggregate relation with itsunique identifier in said first aggregate field, and said secondaggregate field set to the value of the unique identifier of one parentclass record of said parent class relation; (ii) for each of zero ormore child records in said aggregate, storing one record in the linkrelation with said first link field set to the value of the uniqueidentifier of said aggregate record, and said second link field set tothe value of the unique identifier of a child class record of said childclass relation; (iii) whereby said aggregate will be represented byexactly one record in said aggregate relation uniquely identifying saidparent class record, and by zero or more link records in said linkrelation uniquely identifying said child class record(s); and (iv)whereby a two level hierarchy or aggregate associating one record of afirst, parent class and zero or more records of a second, child class isaccurately represented.
 2. A two level hierarchy called an aggregate,associating one record of a first, parent class and zero or more recordsof a second, child class, each of said classes is being definedrespectively by a parent class relation and a child class relationwithin a relational database, comprising: (a) an aggregate relationwhose aggregate relation record schema comprises; (i) a single aggregaterecord among a set of aggregate records in said aggregate relationuniquely identified by data within said aggregate relation recordschema; (ii) a single parent class record among a set of parent classrecords in said parent class of said parent class relation uniquelyidentified by data within said aggregate relation record schema; (b) alink relation within a link relation record schema including: (i) asingle aggregate record among the set of aggregate records in saidaggregate relation uniquely identified by data within said link relationschema; (ii) a single child class record of said class among all childclass records in said child class relation uniquely identified by datawithin the link relation schema; (c) representation data representingeach aggregate by; (i) storing one aggregate record in said aggregaterelation uniquely identifying one parent class record among all parentclass records within said parent class relation; (ii) storing zero ormore link records in said link relation, each of which link recorduniquely identifies said aggregate record, and uniquely identifies onechild class record among all records within said child class relation;(iii) whereby each record of said aggregate is represented by exactlyone record in said aggregate relation identifying said parent classrecord and zero or more records in said link relation, each identifyingone child class record; and (iv) whereby a two level hierarchy oraggregate associating one record of said first, parent class and zero ormore records of said second, child will be accurately and unambiguouslyrepresented.
 3. A method for creating and managing a two-levelhierarchical data structure in at least one relational databasemanagement system (RDBMS), comprising the steps of: (a) creating aparent object relation table in said RDBMS g a plurality of parentobject relation records; (b) creating a child object relation table insaid RDBMS having a plurality of child object relation records; (c)creating an aggregate relation table in said RDBMS having a plurality ofaggregate relation records each having a parent object identity field;(d) creating a link relation table in said RDBMS having zero or morelink relation records, each link relation record having (i) an aggregateidentity field and (ii) a child object identity field; (e) saidaggregate relation records having a parent object identity fieldpointing to a parent object relation record of said plurality of parentobject relation records in said parent object relation table; and (f)said link relation records having an aggregate identity field pointingto an aggregate relation record of said plurality of aggregate relationrecords in said aggregate relation table and to a child object relationrecord of said plurality of child object relation records in said childobject relation table whereby zero or more child object relation recordsare linked to a parent object record relation record.
 4. The method forcreating and managing a two-level hierarchical data structure in atleast one relational database management system of claim 3, comprisingthe further steps of: (a) providing a first link relation record of saidplurality of link relation records having (i) a first aggregate identityfield pointing to a first aggregate relation record of said plurality ofaggregate relation records associated with a first parent objectrelation record of said plurality of parent object relation records, and(ii) a first child object identity field adapted to point to singlechild object relation record within said child object relation table;and (b) providing a second link relation record of said plurality oflink relation records differing from said first link relation recordhaving (i) a second aggregate identity field pointing to a secondaggregate relation record of said plurality of aggregation recordsassociated with a second parent object relation record of said pluralityof parent object relation records, and (ii) a second child objectidentity field adapted to point to a single child object relation recordwithin said child object relation table.
 5. The method for creating andmanaging a two-level hierarchical data structure in at least onerelational database management system of claim 4, comprising the furtherstep of providing a first child object relation record within said childobject relation table.
 6. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 5, comprising the further steps of:(a) pointing said first child object identity field of said first linkrelation record of said plurality of link relation records to said firstchild object relation record; (b) pointing said second child objectidentity field of said second link relation record of said plurality oflink relation records to said first child object relation record; and(c) whereby said first child object relation record is linked to bothsaid first parent object relation record and said second parent objectrelation record to provide a first linked child object relation record.7. The method for creating and managing a two-level hierarchical datastructure in at least one relational database management system of claim5, comprising the further steps of: (a) providing a second child objectrelation record within said child object relation table; (b) pointingsaid second child object identity field of said second link relationrecord of said plurality of link relation records to said second childobject relation record; and (c) whereby said first child object relationrecord is linked to said first parent object relation record and saidsecond child object relation record is linked to said second parentobject relation record.
 8. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 7, wherein said second child objectrelation record is identical to said first child object relation record.9. The method for creating and managing a two-level hierarchical datastructure in at least one relational database management system of claim6, wherein said parent object relation table comprises a first schemahaving a first schema organization including a first key for identifyinga parent object relation record of said parent object relation records.10. The method for creating and managing a two-level hierarchical datastructure in at least one relational database management system of claim9, wherein said child object relation table comprises a second schemahaving a second schema organization including a second key foridentifying a first child object relation record of said child objectrelation table.
 11. The method for creating and managing a two-levelhierarchical data structure in at least one relational databasemanagement system of claim 10, wherein said aggregate relation tablecomprises a third schema having a third schema organization including athird key for identifying an aggregate relation record of said pluralityof aggregate relation records.
 12. The method for creating and managinga two-level hierarchical data structure in at least one relationaldatabase management system of claim 11, wherein said link relation tablecomprises a fourth schema having a fourth schema organization includinga fourth key for identifying a link relation record of said plurality oflink relation records.
 13. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 12, comprising the further step ofaltering a relationship between a third parent object relation record ofsaid plurality of parent object relation records and said first childobject relation record independently of any changes to said third parentobject relation record and independently of any changes to said firstchild object relation record.
 14. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 13, comprising the further step ofaltering said relationship between said third parent object relationrecord and said first child object relation record by changing anaggregate identity field of a link relation record of said plurality oflink relation records.
 15. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 13, comprising the further step ofaltering said relationship between said third parent object relationrecord and said first child object relation record by changing a childobject identity field of a link relation record of said plurality oflink relation records.
 16. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 13, comprising the further step ofaltering said relationship between said third parent object relationrecord and said first child object relation record by changing a parentobject identity field of an aggregate relation record of said pluralityof aggregate relation records.
 17. The method for creating and managinga two-level hierarchical data structure in at least one relationaldatabase management system of claim 6, comprising the further steps of:(a) providing a plurality of child object relation records includingtherein a plurality of associated child object relation records, allassociated child object relation records of said plurality of associatedchild object relation records being associated with a fourth parentobject relation record; and (b) determining said associated child objectrelation records within said plurality of associated child objectrelation records in accordance with said link relation table.
 18. Themethod for creating and managing a two-level hierarchical data structurein at least one relational database management system of claim 6,wherein said first child object relation record further comprises achild object identity field and (i) said first child identity field ofsaid first link relation record, and (ii) said second child identityfield of said second link relation record, both point to said childobject identity field of said first child object relation record. 19.The method for creating and managing a two-level hierarchical datastructure in at least one relational database management system of claim6, wherein said first and second aggregate relation records includerespective first and second aggregate identity fields and said firstaggregate identity field of said first link relation record points tosaid first aggregate identity field of said first aggregate relationrecord and said second aggregate identity field of said second linkrelation record points to said second aggregate identity field of saidsecond aggregate relation record.
 20. The method for creating andmanaging a two-level hierarchical data structure in at least onerelational database management system of claim 6, comprising the furthersteps of: (a) providing fifth and sixth parent object relation recordswithin said parent object relation table; (b) providing a fifth childobject relation record within said child object relation table; (c)providing third and fourth aggregate relation records of said pluralityof aggregate relation records having parent object identity fieldspointing to said fifth and sixth parent object relation recordsrespectively; (d) providing third and fourth link relation records ofsaid plurality of link relation records having (i) respective third andfourth aggregate identity fields pointing to said third and fourthaggregate relation records, and (ii) a third and fourth child objectidentity fields pointing to said third child object relation record; and(e) whereby said third child object relation record is linked to saidfifth and sixth parent object relation records to provide a secondlinked child object relation record in addition to said first linkedchild object relation record.
 21. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 20, wherein said first and secondparent object relation records linked to said first child objectrelation record and said fifth and sixth parent object relation recordslinked to said third child object relation record are mutuallyexclusive.
 22. The method for creating and managing a two-levelhierarchical data structure in at least one relational databasemanagement system of claim 20, wherein said first and second parentobject relation records comprise at least one of said third and fourthparent object relation records.
 23. The method for creating and managinga two-level hierarchical data structure in at least one relationaldatabase management system of claim 20, wherein said first child objectrelation record comprises said third child object relation record. 24.The method for creating and managing a hierarchical data structure in atleast one relational database management system of claim 6, wherein saidparent object relation table is disposed in a first RDBMS and said childobject relation table is disposed in a second RDBMS.
 25. The method forcreating and managing a hierarchical data structure in at least onerelational database management system of claim 6, comprising the furtherstep of providing fifth and sixth aggregate relation records of saidplurality of aggregate relation records having respective parent objectidentity fields both pointing to a seventh parent object relationrecord.
 26. The method for creating and managing a hierarchical datastructure in at least one relational database management system of claim25, wherein said fifth and sixth aggregate relation records are linkedto differing child object relation records of said plurality of childobject relation records.
 27. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 26, comprising the step of altering therelationships of said differing children to said seventh parent objectrelation record.
 28. The method for creating and managing a hierarchicaldata structure in at least one relational database management system ofclaim 6, wherein the step of providing said first child object relationrecord comprises the step of inserting a link relation record into saidlink relation table.
 29. The method for creating and managing atwo-level hierarchical data structure in at least one relationaldatabase management system of claim 6, comprising the further steps of:(a) providing an eighth parent object relation record of said pluralityof parent object records; (b) providing a fifth aggregate relationrecord of said plurality of aggregate relation records having a fifthparent object identity field pointing to said eighth object relationrecord; (c) providing a fifth link relation record of said plurality oflink relation records having: (i) a fifth aggregate identity fieldpointing to said fifth aggregate relation record; and (ii) a fifth childobject identity field pointing to said first child object relationrecord whereby said first child object relation record is linked to saidfirst, second and eighth parent object relation records.
 30. The methodfor creating and managing a hierarchical data structure in at least onerelational database management system of claim 6, further comprising thestep of creating an object type descriptor table having object relationretrieval information for retrieving a selected object relation from aselected one of said parent object relation table and said child objectrelation table.
 31. The method for creating and managing a hierarchicaldata structure in at least one relational database management system ofclaim 30, wherein said object relation retrieval information furthercomprises information for specifying a selected host relational serverwherein said selected object relation is disposed within said selectedrelational server.
 32. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 31, wherein said object relation retrievalinformation further comprises information for specifying a networkaddress of said host selected relational server.
 33. The method forcreating and managing a hierarchical data structure in at least onerelational database management system of claim 32, wherein said objectrelation retrieval information further comprises information forspecifying a name of a relational database.
 34. The method for creatingand managing a hierarchical data structure in at least one relationaldatabase management system of claim 33, wherein said object relationretrieval information further comprises information for specifying aname of said selected object relation.
 35. The method for creating andmanaging a hierarchical data structure in at least one relationaldatabase management system of claim 34, wherein said object relationretrieval information further comprises information for specifyingwhether said selected object relation is a parent object relation or achild object relation.
 36. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 34, including first and second selectedobject relations wherein said parent object relation table and saidchild object relation table are disposed in differing relationaldatabases.
 37. The method for creating and managing a hierarchical datastructure in at least one relational database management system of claim30, wherein said object relation retrieval information further comprisesinformation for specifying a type classification of said selected objectrelation.
 38. The method for creating and managing a hierarchical datastructure in at least one relational database management system of claim30, comprising the further steps of: (a) creating a link type relationtable having a plurality of link types; and (b) providing a link typepointer within a selected link relation record of said plurality of linkrelation records pointing to a link type of said plurality of link typesfor identifying a link type associated with said selected link relationrecord.
 39. The method for creating and managing a hierarchical datastructure in at least one relational database management system of claim31, said aggregate type relation: (a) a first aggregate relationspecifying pointer for specifying a parent object type relation in saidobject type descriptor table; (b) a second aggregate relation specifyingpointer for specifying a child object type relation in said object typedescriptor table; and (c) a third aggregate relation specifying pointerfor specifying a link type relation in said link type relation table.40. A method for creating and managing a two-level hierarchical datastructure in at least one relational database management system,comprising the steps of: (a) creating an object relation table in saidRDBMS having a plurality of object relation records, including aplurality of parent object relation records and zero or more childobject relation records; (b) creating an aggregate relation table insaid RDBMS having a plurality of aggregate relation records; (c)creating a link relation table in said RDBMS having a plurality of linkrelation records; (d) said aggregate relation records having a parentobject pointer pointing to a parent object relation record of saidplurality of parent object relation records in said object relationtable; and (e) said link relation records having (i) a plurality ofaggregate relation pointers pointing to aggregate relation records ofsaid plurality of aggregate relation records in said aggregate relationtable, and (ii) zero or more child object pointers adapted to point to asingle child object relation record in said object relation table. 41.The method for creating and managing a hierarchical data structure in atleast one relational database management system of claim 40, comprisingthe further steps of: (a) creating an object type relation table havinga plurality of object types; and (b) providing an object type pointerwithin a selected object relation record of said plurality of objectrelation records pointing to an object type of said plurality of objecttypes for identifying an object type associated with said selectedobject relation record.
 42. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 41, comprising the further steps of: (a)creating a link type relation table having a plurality of link types;and (b) providing a link type pointer within a selected link relationrecord of said plurality of link relation records pointing to a linktype of said plurality of link types for identifying a link typeassociated with said selected link relation record.
 43. The method forcreating and managing a hierarchical data structure in at least onerelational database management system of claim 41, further comprisingthe steps of: (a) creating an aggregate type relation table having aplurality of aggregate types; and (b) providing an aggregate typepointer within a selected aggregate relation record of said plurality ofaggregate relation records pointing to an aggregate type of saidplurality of aggregate types for identifying an aggregate typeassociated with said selected aggregate relation record.
 44. The methodfor creating and managing a hierarchical data structure in at least onerelational database management system of claim 43, said aggregate typerelation comprising: (a) a first aggregate relation specifying pointerfor specifying a parent object type relation in said object typedescriptor table; and (b) a second aggregate relation specifying pointerfor specifying a child object type relation in said object typedescriptor table.
 45. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 41, comprising the further steps of: (a)creating a link type table having a plurality of link types; (b)providing a link type pointer within a selected link relation record ofsaid plurality of link relation records pointing to a link type of saidplurality of link types for identifying a link type associated with saidselected link relation record; (c) creating an aggregate type relationtable having a plurality of aggregate types; and (d) providing anaggregate type pointer within a selected aggregate relation record ofsaid plurality of aggregate relation records pointing to an aggregatetype of said plurality of aggregate types for identifying an aggregatetype associated with said selected aggregate relation record.
 46. Themethod for creating and managing a hierarchical data structure in atleast one relational database management system of claim 45, saidaggregate type relation comprising: (a) a first aggregate relationspecifying pointer for specifying a parent object type relation in saidobject type descriptor table; (b) a second aggregate relation specifyingpointer for specifying a child object type relation in said object typedescriptor table; and (c) a third aggregate relation specifying pointerfor specifying a link type relation in said link type relation table.47. A two-level hierarchical data structure in a relational databasemanagement system (RDBMS), comprising: (a) a parent object relationtable in said RDBMS having a plurality of parent object relationrecords; (b) a child object relation table in said RDBMS adapted toreceive a first child object relation record; (c) an aggregate relationtable in said RDBMS having a plurality of aggregate relation recordseach having a parent object identity field; (d) a link relation table insaid RDBMS having a plurality of link relation records each having (i)an aggregate identity field and (ii) a child object identity field; (e)said aggregate relation records having a parent object identity fieldpointing to a parent object relation record in said parent objectrelation table; (f) said link relation records having an aggregateidentity field pointing to an aggregate of said aggregate relationrecords and a child object identity field pointing to a child objectrelation record;
 48. The two-level hierarchical data structure in atleast one relational database management system of claim 47, furthercomprising: (a) a first link relation record of said plurality of linkrelation records having (i) a first aggregate identity field pointing toa first aggregate relation record of said plurality of aggregaterelation records associated with a first parent object relation recordof said plurality of parent object relation records, and (ii) a firstchild object identity field adapted to point to said single child objectrelation record within said child object relation table; and (b) asecond link relation record of said plurality of link relation recordsdiffering from said first aggregate relation record having (i) a secondaggregate identity field pointing to a second aggregate relation recordof said plurality of aggregation records associated with a second parentobject relation record of said plurality of parent object relationrecords, and (ii) a second child object identity field adapted to pointto said single child object relation record within said child objectrelation table.
 49. The two-level hierarchical data structure in atleast one relational database management system of claim 48, furthercomprising a first child object relation record within said child objectrelation table.
 50. The two-level hierarchical data structure in atleast one relational database management system of claim 49, furthercomprising: (a) said first child object identity field of said firstlink relation record of said plurality of link relation records pointingto said first child object relation record; (b) said second child objectidentity field of said second link relation record of said plurality oflink relation records pointing to said first child object relationrecord; and (c) whereby said first child object relation records islinked to said first parent object relation record and said secondparent object relation record to provide a first linked object relationrecord.
 51. The two-level hierarchical data structure in at least onerelational database management system of claim 50, further comprising:(a) a second child object relation record within said child objectrelation table; (b) said second child object identity field of saidsecond link relation record of said plurality of link relation recordspointing to said second child object relation record; and (c) wherebysaid first child object relation record is linked to said first parentobject relation record and second child object relation record isrecursively linked to said second parent object relation record.
 52. Thetwo-level hierarchical data structure in at least one relationaldatabase management system of claim 49, further comprising an alteringof a relationship between a first selected parent object relation recordof said plurality of object relation records and said first child objectrelation record provided independently of any changes to said selectedparent object relation record and independently of any changes to saidchild object identity field.
 53. The two-level hierarchical datastructure in at least one relational database management system of claim52, further comprising an altering of said relationship between saidfirst selected parent object relation record and said first child objectrelation record provided by changing an aggregate identity field of alink relation record of said plurality of link relation records.
 54. Thetwo-level hierarchical data structure in at least one relationaldatabase management system of claim 53, further comprising an alteringof said relationship between said first selected parent object relationrecord and said first child object relation record provided by changinga value of said third key.
 55. The two-level hierarchical data structurein at least one relational database management system of claim 50,further comprising (a) a plurality of child object relation recordsincluding therein a plurality of associated child object relationrecords, each associated child object relation record of said pluralityof associated child object relation records being associated with asecond selected parent object relation record; and (b) a determinationof said associated child object relation records within said pluralityof associated child object relation records in accordance with said linkrelation table.
 56. The two-level hierarchical data structure in atleast one relational database management system of claim 50, whereinsaid first child object relation record further comprises a child objectidentity field, and (i) said first child identity field of said firstlink relation record, and (ii) said second child identity field of saidsecond link relation record both point to said child object identityfield of said first child object relation record.
 57. The two-levelhierarchical data structure in at least one relational databasemanagement system of claim 49, wherein first and second aggregaterelation records include respective first and second aggregate identityfields and said first aggregate identity field of said first linkrelation record points to said first aggregate identity field of saidfirst aggregate relation record and said second aggregate identity fieldof said second link relation record points to said second aggregaterelation identity field of said second aggregate relation record. 58.The two-level hierarchical data structure in at least one relationaldatabase management system of claim 48, further comprising: (a) a fifthparent object relation record of said plurality of parent objectrelation records; (b) a fifth aggregate relation record of saidplurality of aggregate relation records having a fifth parent objectidentity field; and (c) a fifth link relation record of said pluralityof link relation records having (i) a fifth aggregate identity fieldpointing to said fifth aggregate relation record, and (ii) a fifth childobject identity field pointing to said first child object relationrecord whereby said first child object relation record is linked to saidfirst, second and third parent objection relation records.
 59. Thetwo-level hierarchical data structure in at least one relationaldatabase management system of claim 48, wherein said first child objectrelation table comprises said first parent object relation table,whereby said first link child object relation record and said firstparent object relation record are included in a single object relationtable.
 60. The two-level hierarchical data structure in at least onerelational database management system of claim 50, further comprising:(a) an aggregate type relation table having a plurality of aggregatetypes; (b) an aggregate type pointer within a selected aggregaterelation record of said plurality of aggregate relation records pointingto an aggregate type of said plurality of aggregate types foridentifying an aggregate type of said plurality of aggregate typesassociated with said selected aggregate relation record; (c) an objecttype descriptor table having a plurality of object types having aplurality of parent object type pointers for pointing to a selectedparent object relation record in said parent object relation tablethereby providing a descriptor-indicated parent object relation recordfor identifying an object type of said plurality of object typesassociated with said descriptor-indicated parent object relation record;and (d) said object type descriptor table having zero more child objecttype pointers for pointing to a selected child object relation record insaid child object relation table thereby providing adescriptor-indicated child object relation record for identifying anobject type of said plurality of object types associated with saiddescriptor-indicated child object relation record.
 61. The two-levelhierarchical data structure in at least one relational databasemanagement system of claim 58, further comprising: (a) a link typerelation table in said RDBMS having a plurality of link types; and (b) alink type pointer within a selected link relation record of saidplurality of link relation records pointing to a link type of saidplurality of link types for identifying a link type associated with saidselected link relation record.
 62. The method for creating and managinga hierarchical data structure in at least one relational databasemanagement system of claim 60, said aggregate type relation comprising:(a) a first aggregate relation specifying pointer for specifying aparent object type relation in said object type descriptor table; (b) asecond aggregate relation specifying pointer for specifying a childobject type relation in said object type descriptor table; and (c) athird aggregate relation specifying pointer for specifying a link typerelation in said link type relation table.
 63. A two-level hierarchicaldata structure in at least one relational database management system,comprising: (a) an object relation table in said RDBMS having aplurality of object relation records, including a plurality of parentobject relation records and zero or more child object relation records;(b) an aggregate relation table in said RDBMS having a plurality ofaggregate relation records; (c) a link relation table in said RDBMShaving a plurality of link relation records; (d) said aggregate relationrecords having a parent object pointer pointing to a parent objectrelation record of said plurality of parent object relation records insaid object relation table; and (e) said link relation records having(i) a plurality of aggregate relation pointers pointing to aggregaterelation records of said plurality of aggregate relation records in saidaggregate relation table, and (ii) one or more child object pointersadapted to point to a single child object relation record in said objectrelation table.
 64. The hierarchical data structure in at least onerelational database management system of claim 63, further comprising:(a) an object type relation table having a plurality of object types;and (b) an object type pointer within a selected object relation recordof said plurality of object relation records pointing to an object typeof said plurality of object types for identifying an object typeassociated with said selected object relation record.
 65. Thehierarchical data structure in at least one relational databasemanagement system of claim 64, further comprising: (a) a link typerelation table having a plurality of link types; (b) a link type pointerwithin a selected link relation record of said plurality of linkrelation records pointing to a link type of said plurality of link typesfor identifying a link type associated with said selected link relationrecord.
 66. The hierarchical data structure in at least one relationaldatabase management system of claim 64, further comprising: (a) anaggregate type relation table having a plurality of aggregate types; and(b) an aggregate type pointer within a selected aggregate relationrecord of said plurality of aggregate relation records pointing to anaggregate type of said plurality of aggregate types for identifying anaggregate type associated with said selected aggregate relation record.67. The hierarchical data structure in at least one relational databasemanagement system of claim 66, further comprising at least oneadditional pointer within a further selected aggregate relation recordof said plurality of aggregate relation records pointing to an objecttype of said plurality of object types for identifying an object typeassociated with said further selected aggregate record.
 68. Thehierarchical data structure in at least one relational databasemanagement system of claim 64, further comprising (a) a link typerelation table having a plurality of link types; and (b) a link typepointer within a selected link relation record of said plurality of linkrelation records pointing to a link type of said plurality of link typesfor identifying a link type associated with said selected link relationrecord; (c) an aggregate type relation table having a plurality ofaggregate types; and (d) an aggregate type pointer within a selectedaggregate relation record of said plurality of aggregate relationrecords pointing to an aggregate type of said plurality of aggregatetypes for identifying an aggregate type associated with said selectedaggregate relation record.
 69. The method for creating and managing ahierarchical data structure in at least one relational databasemanagement system of claim 68, said aggregate type relation comprising:(a) a first aggregate relation specifying pointer for specifying aparent object type relation in said object type descriptor table; (b) asecond aggregate relation specifying pointer for specifying a childobject type relation in said object type descriptor table; and (c) athird aggregate relation specifying pointer for specifying a link typerelation in said link type relation table.